Computerized mapping products are achieving widespread use today. Such mapping programs are commonly used to automate the task of calculating a route from a starting destination to an ending destination. For the purpose of this discussion, the term "destination" means a point or location on the map at which the user indicates a desire to either start a trip, end the trip, or visit along the trip. A destination may also be known by other names, such as via, vertex, node, stop, or the like. Most mapping programs allow a user to include additional destinations to be visited along the route. The route is typically displayed in a graphical format, allowing the user to visualize the trip. However, existing mapping programs suffer from several problems related to altering a route once it has been calculated.
First, existing mapping programs do not provide a simple mechanism for a user to add a destination to a trip after the route has already been calculated. In other words, if the user identifies some number of destinations to be visited on a trip and then calculates a route to visit all of those destinations, the user cannot easily add a new destination to the trip or substitute a new destination for an existing destination. One reason for the difficulty is that the mapping program must be able to identify where along the route a new destination should be inserted. When adding a new destination, the mapping program must insert the new destination at a point that ensures the new route is reasonably efficient. That task is much more computationally burdensome than it might at first appear.
Computing an ideal order for the destinations to be visited prior to calculating the new route is a problem that mapping-program designers struggle with constantly. Those skilled in the art will appreciate that if a mapping program must compute an ideal order for the destinations, the time required to perform that computation results in an undesirable delay to the user. As a result, most mapping programs simply do not compute a new order, but, rather, add the new destination to the end of the list of existing destinations, which most often results in disjointed routes that are not practical. It would be preferable to allow the user to directly identify the order in which the destinations are visited and, ideally, without undue delay to the user. However, with existing mapping programs, allowing the user to directly identify the order requires substantial manual input and is not intuitively achieved. With existing mapping programs, the user must perform the several steps of deleting an existing destination, inserting the new destination (and possibly having to manually reorder the destinations), and then calculating the entire route anew.
Another problem with existing mapping programs is that imperfect data sometimes results in a route that is impassable. For example, if a one-way street is incorrectly identified as two-way in the mapping data, the mapping program may calculate a route that travels the wrong way down that one-way street. Although the user may have personal knowledge of the inaccuracy, existing mapping programs do not allow the user to easily redirect the route around the one-way street.
Yet another problem with existing mapping programs is that they do not easily allow the user to redirect the route along an alternative path. Often, the user may have a desire to include a particular street or highway along the route as an alternative to those calculated. Perhaps the desired highway borders an ocean or a lake and provides a pleasant view. Perhaps the user has personal knowledge of construction occurring along the calculated route. Existing mapping programs are unable to easily accommodate the user's desire. For two given destinations, the mapping program calculates the same route every time based on route-selection criteria defined in the mapping program. Existing mapping programs do not have a mechanism for easily allowing the user to override the route-selection criteria for a portion of the route and thereby redirect that portion of the route to an alternative path.
Still another problem with existing mapping programs is the situation where a user attempts to calculate a route between generally-described destinations, such as between two cities. Often, the user provides to the mapping program the name of a city as a destination without a more specific descriptor, such as an address. In that case, the mapping program is forced to pick an arbitrary destination within the city, often a pre-selected "city center," the centroid of the city or a famous landmark, for the destination of the route. The user may desire to move the pre-selected destination to a more accurate destination, such as a particular address or building. With existing mapping programs, the user cannot easily relocate the arbitrarily selected destination without reentering the destinations with the more specific descriptors.
Those and other problems render the existing systems and methods less than satisfactory. Until now, an adequate solution to those problems has eluded those skilled in the art. Accordingly, there is a need for a system or method of allowing a user to input, in a simple manner, additional or alternative destinations to be visited along a pre-calculated route. The system or method should also provide the ability to redirect a portion of the calculated route if desired.